Cross-SDK consistency suggestion: The .NET provider-facing row type uses positional arrays (object?[]), but every other SDK uses named key-value maps:

Using positional arrays is more error-prone for SDK users (column order must match Columns exactly), and it means the adapter has to post-process the data into a keyed form before serialization (lines ~294–304). It would be more consistent and simpler to use named rows directly:

// Instead of positional arrays:
public IList<object?[]> Rows { get; set; } = [];

// Use named rows (consistent with other SDKs):
public IList<IDictionary<string, object?>> Rows { get; set; } = [];

If this change is made, the adapter's conversion block that builds keyedRows from positional data (~lines 294–304) could be removed, since the provider would already return named rows directly.

The Columns field can be kept for its own value (e.g., to know column order in SELECT results), just like the other SDKs retain it.

The row type intentionally varies per language based on what's idiomatic and efficient:

• .NET: IList<object?[]> — positional arrays are natural (ADO.NET readers give you positional data). The adapter converts to keyed maps for the wire format.
• TypeScript: Record<string, unknown>[] — dicts are the natural JS type.
• Go/Python: map[string]any / dict[str, Any] — natural map types, match the wire format directly.
• Rust: Vec<HashMap<String, Value>> — matches the wire format (generated RPC type), so the adapter passes rows through with zero conversion.

Changing Rust to positional arrays would mean the adapter has to rebuild a HashMap for every row on every query — pointless overhead since the wire format requires keyed maps anyway. Each language's choice minimizes conversion while staying idiomatic.

Cross-SDK naming inconsistency: This class is named SessionFsSqliteResult, but all other SDKs name the equivalent type SessionFsSqliteQueryResult:

• Go: SessionFsSqliteQueryResult (go/session_fs_provider.go)
• Node.js: SessionFsSqliteQueryResult (nodejs/src/sessionFsProvider.ts)
• Python: SessionFsSqliteQueryResult (python/copilot/session_fs_provider.py)
• Rust: SessionFsSqliteQueryResult (rust/src/session_fs.rs)
• .NET: SessionFsSqliteResult ← missing "Query"

Suggestion: Rename to SessionFsSqliteQueryResult to align with the other SDKs. This is a public API type and the name divergence could confuse developers working across languages.

Cross-SDK type inconsistency: LastInsertRowid is typed as long? here, but all other SDKs use a floating-point type for this field:

• Go: *float64
• Rust: Option<f64>
• Python: float | None
• Node.js: number | undefined (via Omit<GeneratedSqliteQueryResult, "error">)
• The generated wire-format RPC type in .NET itself also uses double? (see SessionFsSqliteQueryResult in Rpc.cs)

Using long? is semantically reasonable since SQLite rowids are always integers, but it diverges from the rest of the SDK surface. It also means there's an implicit long → double widening in the adapter (result?.LastInsertRowid at line 297), which could lose precision for rowids > 2^53 on paper (unlikely in practice).

Suggestion: Use double? to match the wire type and other SDKs. If you prefer integer semantics, consider adding a // SQLite rowids are always integers; cast is safe comment in the adapter.

Cross-SDK behavioral inconsistency: When provider.sqlite is absent (unsupported), this throws an error — which propagates as a JSON-RPC error response to the runtime. The other three SDKs return a structured in-band response instead:

• Go: return &rpc.SessionFsSqliteQueryResult{ Error: &rpc.SessionFsError{Code: UNKNOWN, Message: "SQLite is not supported..."} }, nil
• Python: return _GeneratedSqliteQueryResult(... error=SessionFSError(..., message="SQLite is not supported..."))
• .NET: return new SessionFsSqliteQueryResult { Error = new SessionFsError { ... } }

The same divergence applies to sqliteExists at line 204: the other SDKs return {exists: false} while this throws.

The comment above explains the rationale for letting errors propagate (FS errno mapping isn't meaningful for SQL), which is a fine approach for provider-thrown errors. But the "not supported" case is different — it's a capability check, not a provider error, and returning a structured response may give the runtime more useful information than an unexpected JSON-RPC fault.

Suggestion: Consider returning an in-band error (matching the Go/Python/.NET pattern) for the "not supported" path, even if provider-thrown query errors continue to propagate:

sqliteQuery: async ({ queryType, query, params: bindParams }) => {
    if (!provider.sqlite) {
        return { rows: [], columns: [], rowsAffected: 0, error: { code: "UNKNOWN", message: "SQLite is not supported by this provider" } };
    }
    // provider errors still propagate
    const result = await provider.sqlite.query(queryType, query, bindParams);
    return result ?? { rows: [], columns: [], rowsAffected: 0 };
},

Behavioral inconsistency with Node.js for the "SQLite unsupported" case:

• Python (here): returns a result-level error (error=SessionFSError(code=UNKNOWN, ...))
• Node.js: throw new Error("SQLite is not supported by this provider") — i.e. raises a JSON-RPC protocol error

The Node.js comment explicitly says SQLite errors are intentionally left to propagate to the JSON-RPC layer. But Python takes the opposite approach for the "unsupported" case, returning a result-level error. This means the runtime will observe a different error shape depending on which SDK is in use.

Should this return be a raise to match Node.js?

Behavioral inconsistency with Node.js and Python for SQL execution errors (same issue as go/session_fs_provider.go):

• Node.js: SQL errors propagate to the JSON-RPC layer (no try/catch)
• Python: SQL errors propagate to the JSON-RPC layer (no try/except)
• .NET (here): SQL errors are caught and returned as result-level SessionFsError

If the intent is for SQL errors to propagate (preserving original error detail in the JSON-RPC response), this catch block should be removed. If result-level error wrapping is preferred, Node.js and Python should add equivalent catch blocks.

Note: the previous implementation had catch (Exception ex) when (!IsCriticalException(ex)) — the new bare catch (Exception ex) will now also swallow critical exceptions like OutOfMemoryException. This may be intentional given the redesign, but worth double-checking.

Naming inconsistency with Node.js and .NET: The methods on the separate SessionFsSqliteProvider class are named sqlite_query and sqlite_exists, but:

• Node.js uses query() and exists() on its SessionFsSqliteProvider interface
• .NET uses QueryAsync() and ExistsAsync() on its ISessionFsSqliteProvider interface
• Rust uses sqlite_query() and sqlite_exists() on its SessionFsSqliteProvider trait (same as here)

Since all of these methods live on a type already named SessionFsSqliteProvider, the sqlite_ prefix is redundant. Node.js and .NET chose the shorter names. Having Python/Rust use sqlite_query/sqlite_exists while Node.js uses query/exists and .NET uses QueryAsync/ExistsAsync is an inconsistency in the public API surface.

Suggestion: Rename to query() and exists() in Python (and sqlite_query/sqlite_exists → query/exists in Rust) to align with Node.js and .NET.

Behavioral inconsistency with Node.js and Python for SQL execution errors:

• Node.js: SQL errors propagate to the JSON-RPC layer (no try/catch, intentional per code comment)
• Python: SQL errors propagate to the JSON-RPC layer (no try/except, same design)
• Go (here): SQL errors are caught and returned as result-level SessionFsError

The Node.js code comment says: "Letting exceptions propagate preserves the original error message in the JSON-RPC error response." Go's approach wraps the error in result.Error, which means the runtime sees a different wire format for SQL errors depending on the SDK.

If the intent is to let SQL errors propagate (as in Node.js/Python), this if err != nil block should return an error from the adapter function rather than wrapping it in the result struct. Alternatively, if the Go design of wrapping errors is preferred, Node.js and Python should be updated to match.

sqlite_query return type inconsistency: -> SessionFsSqliteQueryResult (non-optional) vs Node.js query() returning Promise<SessionFsSqliteQueryResult | undefined> and .NET QueryAsync() returning Task<SessionFsSqliteResult?>.

Node.js and .NET allow the provider to return undefined/null for exec-type queries (DDL/multi-statement with no result set), and the adapter substitutes an empty result. Python doesn't have this, meaning Python providers are required to always return a result object even for exec queries.

Consider updating the return type to SessionFsSqliteQueryResult | None and handling it in the adapter (line ~280) to match the Node.js/``.NET behavior.

Cross-SDK naming inconsistency: SessionFsSqliteResult vs SessionFsSqliteQueryResult

All other SDK implementations name the provider-facing query result type SessionFsSqliteQueryResult:

• Node.js: SessionFsSqliteQueryResult (sessionFsProvider.ts)
• Python: SessionFsSqliteQueryResult (session_fs_provider.py)
• Go: SessionFsSqliteQueryResult (session_fs_provider.go)
• Rust: SessionFsSqliteQueryResult (session_fs.rs)

The .NET type here is named SessionFsSqliteResult, dropping the Query segment. Suggest renaming to SessionFsSqliteQueryResult to keep API naming consistent across the SDK family (and match the doc comment on line 11 which already references SessionFsSqliteQueryResult).

// Suggested rename:
public class SessionFsSqliteQueryResult { ... }

Missing SessionFSSqliteQueryType export

SessionFsSqliteProvider is now exported (line 45), and its abstract sqlite_query method signature requires SessionFSSqliteQueryType as the query_type parameter. However, SessionFSSqliteQueryType itself is not exported from the package root.

Node.js re-exports the equivalent type at the package root (SessionFsSqliteQueryType in index.ts). Python users implementing SessionFsSqliteProvider will need to reach into internal modules (copilot.generated.rpc or copilot.session_fs_provider) to get this type, which is inconsistent.

Suggest adding SessionFSSqliteQueryType to both the from .session_fs_provider import (...) block and __all__:

from .session_fs_provider import (
    SessionFsFileInfo,
    SessionFsProvider,
    SessionFsSqliteProvider,
    SessionFsSqliteQueryResult,
+   SessionFSSqliteQueryType,   # re-exported from generated.rpc via session_fs_provider
    create_session_fs_adapter,
)